home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7895 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.0 KB
  1. Path: news.luc.edu!user
  2. From: VArase@varase.it.luc.edu (Verne Arase)
  3. Newsgroups: comp.lang.pl1,comp.lang.c
  4. Subject: Re: PL/I and C
  5. Date: Thu, 29 Feb 1996 09:55:44 -0600
  6. Organization: LUMC
  7. Message-ID: <AD5B28A096683BDAC@mcdiala12.it.luc.edu>
  8. References: <Pine.A32.3.91.960226004311.19148B-100000@black.weeg.uiowa.edu> <4h2qo2$39p2@news-s01.ny.us.ibm.net>
  9. NNTP-Posting-Host: 147.126.240.112
  10.  
  11. In article <4h2qo2$39p2@news-s01.ny.us.ibm.net>,
  12. dwnoon@ibm.net wrote:
  13.  
  14.  >>strings and I haven't run into any trouble yet.  For that matter, you 
  15.  >>could declare an array of longs or Pascal-like strings with length bytes
  16.  
  17.  >>at the beginning and whip up a set of routines to treat those as
  18. strings.
  19.  >>That's the advantage of a language which _doesn't_ have string features 
  20.  >>built in. :)
  21.  >
  22.  >There is nothing to stop you from doing this in PL/I too. It's just that
  23. you
  24.  >don't need to. ... :-)
  25.  
  26. ... and as they're intrinsic to the language, inline optimizations can be
  27. done so the call can even be eliminated ...
  28.  
  29. ---
  30. The above are my own opinions, and not those of my employer.
  31.